System and Method for Preventing Multiple Charges for a Transaction in a Payment System

ABSTRACT

A system and method for preventing multiple charges for a transaction in a payment system is presented. A payment system receives a payment operation request from the order system, and determines whether the payment operation is a duplication of a previous payment operation request. If so, the payment system retrieves stored financial transaction results and provides the financial transaction results to the order system. When the payment operation request is not a duplicate, the payment system contacts a payment provider to receive financial transaction results, which is passed to the order system and stored in a persistent data store.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of commonly assigned,co-pending U.S. Non-Provisional patent application Ser. No. 11/420,040,entitled “System and Method for State-Based Execution and Recovery in aPayment System,” filing date May 24, 2006, Attorney Docket No.RSW920050208US1.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to a system and method for preventingmultiple charges for a transaction in a payment system. Moreparticularly, the present invention relates to a system and method forproviding existing financial transaction results to an order system whenthe order system invokes a duplicate payment operation request.

2. Description of the Related Art

Software-based payment systems today rely upon common techniques toorchestrate financial transactions between external payment providers(e.g., credit card companies). A challenge found with these techniques,however, is that the software-based payment systems may not check forduplicate financial transaction requests. Even though payment systemsmay implement transaction-based techniques to minimize the possibilityof such situations, problems arise when duplicate requests originateexternal to the payment system, such as from order systems that areconnected to the payment system.

In such cases when a payment operation request is driven from aconnected external component, the external component may not providechecks or transactional control for duplicate payment operation requeststo the payment system. Hence, the payment system sends duplicatefinancial transaction requests to the external payment provider. Forexample, an order system may request a payment system to capture adeposit of $50 twice when the order system's original intent was for thedeposit to be captured once.

Furthermore, a challenge found with double charging is that the externalpayment provider may not allow the payment system to retract an executedfinancial transaction request. Meaning, the payment provider may notallow executed financial transaction request “rollbacks” orcancellations. Therefore, even if the payment system discovers a doublecharge, the payment system has to manually send a new financialtransaction request to the payment provider to credit the customer'saccount.

While specific solutions may be proposed for solving duplicate paymentoperation requests that are initiated by an end user (e.g., web-formdouble-submission, invoice double submission), a challenge found is thata payment system may also receive duplicate payment operation requestsfrom order systems that are not directly initiated by an end user.

What is needed, therefore, is a system and method that prevents apayment system from performing duplicate financial transaction requeststo a payment provider when the payment system receives a duplicatepayment operation request from an order system.

SUMMARY

It has been discovered that the aforementioned challenges are resolvedusing a system and method for providing existing financial transactionresults to an order system when the order system invokes a duplicatepayment operation request. A payment system receives a payment operationrequest from the order system, and determines whether the paymentoperation is a duplication of a previous payment operation request. Ifso, the payment system retrieves stored financial transaction resultsand provides the financial transaction results to the order system. Whenthe payment operation request is not a duplicate, the payment systemcontacts a payment provider to receive financial transaction results,which is passed to the order system and stored in a persistent datastore.

A customer places an order with an order system by sending order andpayment details to the order system. For example, the customer may placean order on a web page for office supplies, in which case the order andpayment details may include line item information for the officesupplies along with credit card information to pay for the officesupplies.

While processing the customer's order, the order system generates anorder identifier, which uniquely identifies the customer's order. Theorder system also generates a release identifier, which uniquelyidentifies all or part of the customer's order that plans to ship at thesame time to the customer (e.g., a “package”). The order system sendsthe order identifier, the release identifier, and one or more paymentoperation requests to the payment system. For example, the paymentoperation requests may be a payment instruction validation request, apayment instruction storage request, a process payment instruction afterallocation request, or a process payment instruction after shipmentrequest.

Some payment operation requests involve the payment system sending a“financial transaction request” to a payment provider, which may be anexternal payment provider (e.g., credit card company). When this occurs,the payment provider sends “financial transaction results” back to thepayment system. When received, the payment system sends the financialtransaction results to the order system, and also stores the financialtransaction results in a persistent data store.

In order to identify duplicate payment operation requests generated bythe order system, the payment system uses a detection algorithm. Thedetection algorithm detects duplicate payment operation requests usingthe combination of the order identifier, the release identifier (ifapplicable), and the payment identifier.

When the detection algorithm detects a duplicate payment operationrequest, the detection algorithm does not send a financial transactionrequest to the payment provider. Instead, the detection algorithminstructs the payment provider to retrieve the financial transactionresults previously stored in the persistent data store, and send thefinancial transaction results to the order system. By detectingduplicate payment operation requests, the payment system alleviatesduplicate requests to the payment provider that, in turn, reduces costand eliminates rollback situations.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations, and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the present invention, asdefined solely by the claims, will become apparent in the non-limitingdetailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features, and advantages made apparent to those skilled in theart by referencing the accompanying drawings.

FIG. 1 is a diagram showing a payment system receiving and processingpayment operation requests from an order system;

FIG. 2 is a diagram showing a payment system receiving paymentparameters from an order system, and using the payment parameters toidentify duplicate payment operation requests;

FIG. 3A is a diagram showing interface information for a payment systemthat permits external components to request payment operations;

FIG. 3B is a table showing payment parameters for customer orders;

FIG. 3C is a table showing a list of payment identifiers, orderidentifiers, and release identifiers that correspond to paymentoperation requests;

FIG. 4 is a flowchart showing steps taken in determining whether to senda financial transaction request to a payment provider;

FIG. 5A is a diagram showing a state machine partially completing apayment operation that includes multiple sub-tasks;

FIG. 5B is a diagram showing a state machine completing a partiallycompleted payment operation;

FIG. 6 is a flowchart showing steps taken in completing a paymentoperation on a sub-task-by-sub-task basis; and

FIG. 7 is a block diagram of a computing device capable of implementingthe present invention.

DETAILED DESCRIPTION

The following is intended to provide a detailed description of anexample of the invention and should not be taken to be limiting of theinvention itself. Rather, any number of variations may fall within thescope of the invention, which is defined in the claims following thedescription.

FIG. 1 is a diagram showing a payment system receiving and processingpayment operation requests from an order system. Customer 100 places anorder with order system 110 by sending order and payment details 105.For example, customer 100 may place an order on a web page for officesupplies, in which case order and payment details 105 may include lineitem information for the office supplies along with credit cardinformation to pay for the office supplies.

The embodiment shown in FIG. 1 shows that order system 110 includes four“order phases” to process customer 100's order, which are order capturephase 115, order process phase 120, fulfillment phase 125, and shippingphase 130. Order capture phase 115 receives order and payment details105 from customer 100. Order process phase 120 processes the order oncecustomer 100 completes the order (e.g., checks out). Fulfillment phase125 allocates goods to all or a part of customer 100's order and,shipping phase 130 ships the goods (goods 180) to customer 100. As oneskilled in the art can appreciate, an order system may have more or lessorder phases that what is shown in FIG. 1.

While processing customer 100's order, order system 110 generates anorder identifier, which uniquely identifies customer 100's order. Ordersystem 110 also generates a release identifier, which uniquelyidentifies all or part of customer 100's order that is ready to releasefor shipment. Order system 110 sends the order identifier, the releaseidentifier, and one or more payment operation requests 135 to paymentsystem 140. Payment operation requests 135 may include:

-   -   Payment Instruction Validation Request (during order capture        phase 115);    -   Payment Instruction Storage Request (during order process phase        120);    -   Process Payment Instruction After Allocation Request (during        fulfillment phase 125); and    -   Process Payment Instruction After Shipment Request (during        shipping phase 130).

Some payment operation requests 135 involve payment system 140 sending a“financial transaction request” to payment provider 170, which may be anexternal payment provider (e.g., credit card company). In turn, paymentprovider 170 sends a “financial transaction result” back to paymentsystem 140. When received, payment system 140 sends the financialtransaction results (transaction results 175) to order system 110, andalso stores the financial transaction results in orders and paymentsstore 160.

In many cases, order system 110 may unintentionally send a duplicatepayment operation request 135 to payment system 140. Payment system 140uses detection algorithm 145 to circumvent interaction with paymentprovider 170 when it receives a duplicate payment operation request.Detection algorithm 145 detects duplicate payment operation requestsusing the order identifier, the release identifier (if applicable), anda payment identifier, which includes payment instructions and an orderphase (see FIG. 3C and corresponding text for further details).

When detection algorithm 145 detects a duplicate payment operationrequest, detection algorithm 145 does not send a financial transactionrequest to payment provider 170. Instead, detection algorithm 145instructs payment provider 140 to retrieve the financial transactionresults previously stored in orders and payments store 160, and send thefinancial transaction results (transaction results 175) to order system110. By detecting duplicate payment operation requests, payment system140 alleviates duplicate requests to payment provider 170 that, in turn,reduces cost and eliminates rollback situations (see FIGS. 2-4 andcorresponding text for further details).

In addition to receiving duplicate payment operation requests, eventsmay occur at payment system 140 that prevent a payment operation fromcompleting. For example, payment provider 140 may have completed two outof six “sub-tasks” that comprise a particular payment operation, and afailure occurs during the third sub-task. In these circumstances,payment system 140 uses state machine 150 in order to preventduplication of the two successfully completed sub-tasks.

State machine 150 tracks successfully completed sub-tasks, and storescompletion state data and a state progress identifier in state store165. As a result, when payment system 140 re-initiates a failed paymentoperation, payment system 140 is able to retrieve the state progressidentifier and completion state data from state store 165, and continueprocessing the payment operation at the previously failed sub-task pointinstead of starting at the beginning of the payment operation. Using theexample discussed above, payment system 140 re-initiates the paymentoperation at the third sub-task, which eliminates duplicating the firstand second sub-tasks (see FIGS. 5-7 and corresponding text for furtherdetails).

FIG. 2 is a diagram showing a payment system receiving paymentparameters from an order system, and using the payment parameters toidentify duplicate payment operation requests. As order system 110receives and processes a customer order, order system 110 generatesorder identifier 200 and release identifier 240. During order capturephase 115, order system 110 generates and sends order identifier 200 topayment system 140, which identifies a customer's order, such as“#009793.” Payment system 140 stores order identifier 200 as a paymentparameter (payment parameters 220) in orders and payments store 160.

As order system 110 proceeds through order process phase 120 and reachesfulfillment phase 125, order system 110 generates and sends releaseidentifier 240 to payment system 140. Release identifier 240 identifiesparticular line items of an order that are available and allocated forrelease. Again, payment system 140 stores release identifier 240 as apayment parameter in orders and payments store 160. In turn, ordersystem 110 proceeds to shipping phase 130 and ships goods to thecustomer.

When payment system 140 receives a payment operation request from ordersystem 110, payment system 140 retrieves payment parameters 220 fromorders and payments store 160. In addition, payment system 140 generatesa payment identifier to correspond with the payment operation request(see FIG. 4 and corresponding text for further details). Detectionalgorithm 145 uses the payment identifier, the order identifier, and therelease identifier (if applicable) to determine whether the paymentoperation request is a duplication of a previously received paymentoperation request.

When the payment operation request is a duplication, payment system 140retrieves already stored financial transaction results from orders andpayments store 160, and provides the financial transaction results toorder system 110. When the payment operation request is not a duplicate,payment system 140 sends a financial transaction request to paymentprovider 170. In turn, payment provider 170 sends financial transactionresults to payment system 140, which payment system 140 sends to ordersystem 110 and also stores in orders and payments store 160 (see FIG. 4and corresponding text for further details). Order system 110, ordercapture phase 115, order process phase, 120, fulfillment phase 125,shipping phase 130, payment system 140, detection algorithm 145, ordersand payments store 160, and payment provider 170 are the same as thatshown in FIG. 1.

FIG. 3A is a diagram showing interface information for a payment systemthat permits external components to request payment operations. Anexternal component, such as order system 110, uses interface 300 to senda payment operation request to a payment system (e.g., payment system140). The invention described herein adds lines 305 and 310 to a typicalinterface, which include order identifier information and releaseidentifier information, respectively.

When an order system sends a payment operation request to a paymentsystem, the order system provides an order identifier to the paymentsystem in line 305, which is a unique system-wide identifier that isassigned to a customer's order when the customer places the order. Whenthe order system releases all or part of an order, the order systemassigns a release identifier, which is included in line 310. The releaseidentifier uniquely identifies a set of products in an order that areshipped together, such as a “package” that includes goods, which areshipped to a customer.

Line 315 includes payment instruction information for an order, whichmay include an account number, an account expiration date, an address,and a customer name. The payment system includes the payment instructioninformation in a payment identifier, in which the payment system uses toidentify duplicate payment operation requests (see FIGS. 3C, 4, andcorresponding text for further details).

FIG. 3B is a table showing payment parameters for customer orders. Table320 includes columns 325 through 355. Column 325 includes a list oforder identifiers associated with customer orders. Column 330 includes alist of line items for particular orders (order identifiers). Forexample, the first order identifier in table 320 includes four lineitems. Column 335 includes a list of release identifiers that correspondto one or more line items. The release identifiers are assigned to anorder when their associated goods are available for release. Eachrelease identifier may be associated with a particular “package” that isshipped to a customer.

Columns 340-355 include payment instructions for an order. A customermay provide multiple payment instructions for a single order, such ascharging part of an order to one credit card, and charging the remainingpart of the order to another credit card. Column 340 includes a list ofamounts for particular release identifiers. For example, row 358includes an amount of $60 for release identifier 1111, which includesline items 1 and 2 of order ABCD.

Column 350 includes a list of account numbers, such as credit cardnumbers, to pay for particular line items. And, column 355 includes alist of attributes for the payment instructions, such as expirationdates or card verification numbers.

FIG. 3C is a table showing a list of payment identifiers, orderidentifiers, and release identifiers that correspond to paymentoperation requests. When a payment system receives a payment operationrequest, the payment system logs information in table 360. As a result,the payment system is able to analyze table 360 when it receivessubsequent payment operation requests and determine whether the paymentoperation request is a duplication.

Table 360 includes columns 370-395. Columns 370-380 include a list ofpayment instructions for corresponding orders (see FIG. 3B andcorresponding text for further details). Column 385 includes a list oforder phases that the payment system receives a payment operationrequest. For example, the payment system generated row 398 when itreceived a payment operation request from an order system when the ordersystem was in the fulfillment phase. Columns 390 and 395 include a listof order identifiers and release identifiers, respectively, that thepayment system uses during the detection of duplicate payment operationrequests (see FIG. 4 and corresponding text for further details).

FIG. 4 is a flowchart showing steps taken in determining whether to senda financial transaction request to a payment provider. A payment systemuses a detection algorithm to determine when an order system sends aduplicate payment operation request. Processing commences at 400,whereupon processing receives a payment operation request from ordersystem 110 at step 405. The payment operation request includes paymentparameters, such as an order identifier and a release identifier. Atstep 408, processing creates a payment identifier that includes paymentinstructions as well as an “order phase.” The order phase is an ordersystem's phase at which the payment operation is sent. Processing storesthe created payment identifier in orders and payments store 165. Ordersystem 110 and orders and payments store 160 are the same as that shownin FIG. 1.

A determination is made as to whether a release identifier is availablethat corresponds to the payment operation request (decision 410). Forexample, the order system may have provided a release identifier thatsignifies that particular line items are available for release tofulfillment. If a release identifier is not available, decision 410branches to “No” branch 412 whereupon processing associates the orderidentifier with the payment identifier at step 415. On the other hand,if the release identifier is available, decision 410 branches to “Yes”branch 418 whereupon processing associates the payment identifier withthe order identifier and the release identifier.

At step 430, processing compares the payment identifier, the orderidentifier, and the release identifier (if applicable) to storedtransaction information in orders and payments store 160. Adetermination is made as to whether financial transaction resultsalready exist for the particular identifier combination, signifying thatthe payment operation is a duplicate (decision 440). Processing alsochecks for whether the payment operation request exceeds a maximumamount for an order or a release.

If the identifier combination does not already exist and the paymentrequest does not exceed a maximum amount, decision 440 branches to “No”branch 442 whereupon processing sends a financial transaction request topayment provider 170 that, as a result, provides financial transactionresults. These results are then sent to order system 110 and stored inorders and payments store 165 (step 445). Payment provider 170 is thesame as that shown in FIG. 1.

On the other hand, if a transaction already exits for the paymentrequest, or the payment request is requesting an amount that exceeds alimit, decision 440 branches to “Yes” branch 448 whereupon processingprovides order system 110 with the existing financial transactionresults, and does not interact with payment provider 170 (step 450).Processing ends at 460.

FIG. 5A is a diagram showing a state machine partially completing apayment operation that includes multiple sub-tasks. State machine 150includes five states that correspond to five sub-tasks, which are stateA 500, state B 510, state C 520, state D 530, and state E 540. Examplesof sub-tasks include:

-   -   Retrieve payment information and save to a persistent data        store.    -   Retrieve sets of payment configurations and policies that        determine what financial transactions to perform in order to        process a determined event.    -   Establish communications with an external payment provider.    -   Perform financial transactions by communicating with the        external payment provider.    -   Receive financial transaction results from the external payment        provider, or querying the external payment provider in order to        determine such results.    -   Process results and save them into a persistent data store.    -   Provide appropriate response and make available as the result of        a task.

FIG. 5A shows that state machine 150 proceeded through states 500, 510,and 520, in which case interaction with payment provider 170 occurred atstates 500 and 510. At each state, state machine 150 logs the completionof a sub-task and stores completion state data in state store 165 (seeFIG. 6 and corresponding text for further details). State store 165 isthe same as that shown in FIG. 1.

While proceeding to state D 530, a failure occurred, which preventsstate machine 150 from completing a payment operation. Since statemachine 150 logged sub-task completion state data up to state C 520,state machine 150 is able to resume sub-task processing at state D 530(see FIG. 5B and corresponding text for further details).

FIG. 5B is a diagram showing a state machine completing a partiallycompleted payment operation. State machine 150 previously completedsub-tasks that resulted in the payment operation reaching state C 520,whose completion state data is stored in state store 165 (see FIG. 5Aand corresponding text for further details). As such, state machine 150retrieves the completion state data for state C 520 and resumes paymentoperation processing. Subsequently, state machine 150 completes thepayment operation by proceeding through state D 530 and state E 540. Ascan be seen, state machine 150 interacts with payment provider 170 atstate D 530, but does not duplicate interaction with payment provider170 at state A 500 and state B 510 as shown in FIG. 5A.

FIG. 6 is a flowchart showing steps taken in completing a paymentoperation on a sub-task-by-sub-task basis. Processing commences at 600,whereupon processing retrieves a state progress identifier correspondingto a partially completed payment operation from state store 165 (step610). At step 620, processing uses the state progress identifier toidentify subtasks that have already been completed. For example, thestate progress identifier may be “4,” which signifies that the firstfour sub-tasks of a payment operation completed successfully. Statestore 165 is the same as that shown in FIG. 1.

At step 630, processing selects the next sub-task, which is the sub-taskfollowing the last completed sub-task, and retrieves completion statedata from state store 165. Using the example described above, processingretrieves the fourth sub-tasks completion state data, and selects thefifth sub-task to execute next. At step 640, processing executes thenext sub-task.

A determination is made as to whether the sub-task executed successfully(decision 650). If the sub-task did not execute successfully, decision650 branches to “No” branch 652 whereupon processing saves the samestate progress identifier in state store 165, and processing ends at660.

On the other hand, if the sub-task's execution was successful, decision650 branches to “Yes” branch 658 whereupon processing saves thesub-task's completion state data and increments the state progressidentifier in state store 165 (step 665). A determination is made as towhether processing reached the final state of the payment operation(decision 670). If processing has not reached the final state of thepayment operation, decision 670 branches to “No” branch 672 whereuponprocessing selects (step 675) and processes the next sub-task. Thislooping continues until processing reaches the payment operation's finalstate, at which point decision 670 branches to “Yes” branch 678whereupon processing ends at 680.

In one embodiment, processing may identify a “best path” to complete apayment operation based upon customer payment policies, such as creatingnew payment transactions and canceling older payment transactions. Inthis embodiment, processing may calculate the differences of transactionamounts still pending, and reuse validated, but partially completed,payment instruction transactions in order to provide a better chancethat the transaction is successful.

FIG. 7 illustrates information handling system 701, which is asimplified example of a computer system capable of performing thecomputing operations described herein. Computer system 701 includesprocessor 700 which is coupled to host bus 702. A level two (L2) cachememory 704 is also coupled to host bus 702. Host-to-PCI bridge 706 iscoupled to main memory 708, includes cache memory and main memorycontrol functions, and provides bus control to handle transfers amongPCI bus 710, processor 700, L2 cache 704, main memory 708, and host bus702. Main memory 708 is coupled to Host-to-PCI bridge 706 as well ashost bus 702. Devices used solely by host processor(s) 700, such as LANcard 730, are coupled to PCI bus 710. Service Processor Interface andISA Access Pass-through 712 provides an interface between PCI bus 710and PCI bus 714. In this manner, PCI bus 714 is insulated from PCI bus710. Devices, such as flash memory 718, are coupled to PCI bus 714. Inone implementation, flash memory 718 includes BIOS code thatincorporates the necessary processor executable code for a variety oflow-level system functions and system boot functions.

PCI bus 714 provides an interface for a variety of devices that areshared by host processor(s) 700 and Service Processor 716 including, forexample, flash memory 718. PCI-to-ISA bridge 735 provides bus control tohandle transfers between PCI bus 714 and ISA bus 740, universal serialbus (USB) functionality 745, power management functionality 755, and caninclude other functional elements not shown, such as a real-time clock(RTC), DMA control, interrupt support, and system management bussupport. Nonvolatile RAM 720 is attached to ISA Bus 740. ServiceProcessor 716 includes JTAG and I2C busses 722 for communication withprocessor(s) 700 during initialization steps. JTAG/I2C busses 722 arealso coupled to L2 cache 704, Host-to-PCI bridge 706, and main memory708 providing a communications path between the processor, the ServiceProcessor, the L2 cache, the Host-to-PCI bridge, and the main memory.Service Processor 716 also has access to system power resources forpowering down information handling device 701.

Peripheral devices and input/output (I/O) devices can be attached tovarious interfaces (e.g., parallel interface 762, serial interface 764,keyboard interface 768, and mouse interface 770 coupled to ISA bus 740.Alternatively, many I/O devices can be accommodated by a super I/Ocontroller (not shown) attached to ISA bus 740.

In order to attach computer system 701 to another computer system tocopy files over a network, LAN card 730 is coupled to PCI bus 710.Similarly, to connect computer system 701 to an ISP to connect to theInternet using a telephone line connection, modem 775 is connected toserial port 764 and PCI-to-ISA Bridge 735.

While FIG. 7 shows one information handling system that employsprocessor(s) 700, the information handling system may take many forms.For example, information handling system 701 may take the form of adesktop, server, portable, laptop, notebook, or other form factorcomputer or data processing system. Information handling system 701 mayalso take other form factors such as a personal digital assistant (PDA),a gaming device, ATM machine, a portable telephone device, acommunication device or other devices that include a processor andmemory.

One of the preferred implementations of the invention is a clientapplication, namely, a set of instructions (program code) in a codemodule that may, for example, be resident in the random access memory ofthe computer. Until required by the computer, the set of instructionsmay be stored in another computer memory, for example, in a hard diskdrive, or in a removable memory such as an optical disk (for eventualuse in a CD ROM) or floppy disk (for eventual use in a floppy diskdrive), or downloaded via the Internet or other computer network. Thus,the present invention may be implemented as a computer program productfor use in a computer. In addition, although the various methodsdescribed are conveniently implemented in a general purpose computerselectively activated or reconfigured by software, one of ordinary skillin the art would also recognize that such methods may be carried out inhardware, in firmware, or in more specialized apparatus constructed toperform the required method steps.

While particular embodiments of the present invention have been shownand described, it will be obvious to those skilled in the art that,based upon the teachings herein, that changes and modifications may bemade without departing from this invention and its broader aspects.Therefore, the appended claims are to encompass within their scope allsuch changes and modifications as are within the true spirit and scopeof this invention. Furthermore, it is to be understood that theinvention is solely defined by the appended claims. It will beunderstood by those with skill in the art that if a specific number ofan introduced claim element is intended, such intent will be explicitlyrecited in the claim, and in the absence of such recitation no suchlimitation is present. For non-limiting example, as an aid tounderstanding, the following appended claims contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimelements. However, the use of such phrases should not be construed toimply that the introduction of a claim element by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim element to inventions containing only one such element,even when the same claim includes the introductory phrases “one or more”or “at least one” and indefinite articles such as “a” or “an”; the sameholds true for the use in the claims of definite articles.

1. A computer-implemented method comprising: receiving a paymentoperation request from an order system, the payment operation requestincluding payment parameters; prior to sending a financial transactionrequest to a payment provider, determining, using the paymentparameters, whether a payment operation has completed for the paymentoperation request; in response to determining that the payment operationhas not completed, sending the financial transaction request to thepayment provider; and in response to determining that the paymentoperation for the payment request has completed, the method furthercomprising: retrieving financial transaction results that result fromthe payment operation that was performed prior to receiving the paymentoperation request; and sending the financial transaction results to theorder system.
 2. The method of claim 1 wherein the payment parametersinclude an order identifier and a release identifier, the orderidentifier identifying an order and the release identifier identifyingat least a portion of the order that is released for shipment.
 3. Themethod of claim 1 further comprising: in response to sending thefinancial transaction request, receiving the financial transactionresults from the payment provider, which completes the paymentoperation.
 4. The method of claim 1 further comprising: wherein themethod is performed by a payment system; and wherein the order system,the payment system, and the payment provider are separate entities. 5.The method of claim 2 wherein the determining further comprises: inresponse to receiving the payment operation request, creating a paymentidentifier that includes an order phase, the order phase correspondingto a phase in the order system that sent the payment operation request;associating the order identifier and the release identifier to thepayment identifier; and performing the determining using the paymentidentifier, the order identifier, and the release identifier.
 6. Themethod of claim 5 further comprising: wherein the order phase isselected from the group consisting of an order capture phase, an orderprocess phase, a fulfillment phase, and a shipping phase; and whereinthe payment operation request is selected from the group consisting of apayment instruction validation request, a payment instruction storagerequest, a process payment instruction after allocation request, and aprocess payment instruction after shipment request.
 7. A computerprogram product stored on a computer operable media, the computeroperable media containing instructions for execution by a computer,which, when executed by the computer, cause the computer to implement amethod for detecting duplicate payment operation requests, the methodcomprising: receiving a payment operation request from an order system,the payment operation request including payment parameters; prior tosending a financial transaction request to a payment provider,determining, using the payment parameters, whether a payment operationhas completed for the payment operation request; in response todetermining that the payment operation has not completed, sending thefinancial transaction request to the payment provider; and in responseto determining that the payment operation for the payment request hascompleted, the method further comprising: retrieving financialtransaction results that result from the payment operation that wasperformed prior to receiving the payment operation request; and sendingthe financial transaction results to the order system.
 8. The computerprogram product of claim 7 wherein the payment parameters include anorder identifier and a release identifier, the order identifieridentifying an order and the release identifier identifying at least aportion of the order that is released for shipment.
 9. The computerprogram product of claim 7 wherein the method further comprises: inresponse to sending the financial transaction request, receiving thefinancial transaction results from the payment provider, which completesthe payment operation.
 10. The computer program product of claim 7further comprising: wherein the method is performed by a payment system;and wherein the order system, the payment system, and the paymentprovider are separate entities.
 11. The computer program product ofclaim 8 wherein the method further comprises: in response to receivingthe payment operation request, creating a payment identifier thatincludes an order phase, the order phase corresponding to a phase in theorder system that sent the payment operation request; associating theorder identifier and the release identifier to the payment identifier;and performing the determining using the payment identifier, the orderidentifier, and the release identifier.
 12. The computer program productof claim 11 further comprising: wherein the order phase is selected fromthe group consisting of an order capture phase, an order process phase,a fulfillment phase, and a shipping phase; and wherein the paymentoperation request is selected from the group consisting of a paymentinstruction validation request, a payment instruction storage request, aprocess payment instruction after allocation request, and a processpayment instruction after shipment request.
 13. An information handlingsystem comprising: one or more processors; a memory accessible by theprocessors; one or more nonvolatile storage devices accessible by theprocessors; and a payment operation request tool for detecting duplicatepayment operation requests, the payment operation request tool beingeffective to: receive a payment operation request from an order system,the payment operation request including payment parameters; prior tosending a financial transaction request to a payment provider,determine, using the payment parameters, whether a payment operation hascompleted for the payment operation request; in response to determiningthat the payment operation has not completed, send the financialtransaction request to the payment provider; and in response todetermining that the payment operation for the payment request hascompleted, the method further comprising: retrieving financialtransaction results that result from the payment operation that wasperformed prior to receiving the payment operation request; and sendingthe financial transaction results to the order system.
 14. Theinformation handling system of claim 13 wherein the payment parametersinclude an order identifier and a release identifier, the orderidentifier identifying an order and the release identifier identifyingat least a portion of the order that is released for shipment.
 15. Theinformation handling system of claim 13 wherein the payment operationrequest tool is further effective to: in response to sending thefinancial transaction request, receive the financial transaction resultsfrom the payment provider, which completes the payment operation. 16.The information handling system of claim 14 wherein the paymentoperation request tool is further effective to: in response to receivingthe payment operation request, create a payment identifier that includesan order phase, the order phase corresponding to a phase in the ordersystem that sent the payment operation request; associate the orderidentifier and the release identifier to the payment identifier; andperform the determining using the payment identifier, the orderidentifier, and the release identifier.
 17. The information handlingsystem of claim 16 further comprising: wherein the order phase isselected from the group consisting of an order capture phase, an orderprocess phase, a fulfillment phase, and a shipping phase; and whereinthe payment operation request is selected from the group consisting of apayment instruction validation request, a payment instruction storagerequest, a process payment instruction after allocation request, and aprocess payment instruction after shipment request.